오브젝트 - 코드로 이해하는 객체지향 설계 - 조영호

README

이 문서는 단순히 책을 읽어가며 인상깊었던 내용, 궁금한 질문등을 잠깐 계류시키는 용도로 사용할 겁니다. 깨달은 점이나 질문을 구체화 하기 위해선 반드시 별도의 문서를 작성하고 이 문서에 레퍼런스를 걸어주세요.

Scrap

• 상속은 서브타입 관계를 정의하기 위해 사용된다. 대표적으로 서브타입을 식별하는 방식으로는 IS-A 관계를 만족하는지 여부를 보는 것이다. - p.444

  • 언어적인 어휘가 아니라 기대되는 행동에 따라 타입 계층을 구성해야 한다.
  • "레슨 IS-A 예약" 이 문장은 기대되는 행동이 포함되는가? 즉, 예약에게 기대되는 행동과 레슨에게 기대되는 행동이 서로 호환되는가를 평가해보자.

• 리스코프 치환원칙은 상속관계에 있는 두 클래스 사이의 관계를 클라이언트와 떨어뜨려놓고 판단하지 말라고 속삭인다. 상속관계는 클라이언트 관점에서 자식 클래스가 부모 클래스를 대체할 수 있을때에만 유효하다.

  • 대체가능성을 결정하는 것은 클라이언트다. - p.458

• 계약에 의한 설계는 클라이언트가 정상적으로 메서드를 실행하기 위해 만족시켜야 하는 사전조건 (precondition)과 메서드가 실행된 후에 서버가 메서드에게 보장해야 하는 사후조건(postcondition), 메서드 실행 전-후로 인스턴스가 만족시켜야 하는 클래스 불변식 (class invariant)의 세가지 요소로 구성된다. - p.461, p.540 부록_A

  • Precondition: 메서드가 호출되기 위한 서버의 요구, 클라이언트의 의무.
  • Postcondition: 메서드 실행 후 클라이언트에게 보장해야 하는 조건. 클라이언트가 precondition을 만족시켰다면, 서버는 postcondition을 만족시켜야 할 의무가 있다. 만약 그러지 못할 경우, 클라이언트에게 예외를 던져야 한다.
  • Invariant: 항상 참이라고 보장되는 서버의 조건. 메서드가 실행되는 도중에는 불변식을 만족하지 못할 수도 있으나, 메서드를 실행하기 전이나 종료된 후 불변식은 항상 참이어야 한다.

• 서브타입이 슈퍼타입에 정의된 사전조건을 강화하면 기존에 체결된 계약을 위반하게 된다. 따라서 사전조건 강화는 리스코프 치환원칙을 위반한다. 반대로 사전조건을 완화하는 것은 리스코프 치환원칙을 위반하지 않는다. - p.552

• 부모 클래스보다 못한 자식 클래스는 서브타입이 아니다. - p.561

  • 펭귄은 날 수 없다. 새는 날 수 없다. 새는 날 수 있다. 그러면 펭귄은 새인가?

• 너무 이른 시기에 데이터에 초점을 맞추면 객체의 캡슐화가 약화되기 때문에 낮은 응집도와 높은 결합도를 가진 객체들로 넘쳐나게 된다. - p.134

  • 트랜잭션 스크립트와 같은 단순한 CRUD가 주된 모델들은 예외이지 않을까? 여기서 말하는 책임은 대부분 비즈니스 로직과 정책이 들어간 "행동"이 들어가는 모델들이니까.

• INFORMATION EXPERT 정보 전문가 패턴은 객체가 자신이 소유하고 있는 정보와 관련된 작업을 수행한다는 일반적인 직관을 표현한 것이다. 그런데 여기서 말하는 정보는 데이터와는 다르다는 사실에 주의하라. 책임을 수행하는 객체가 정보를 '알고' 있다고 해서 그 정보를 '저장'하고 있을 필요는 없다. 객체는 해당 정보를 제공할 수 있는 다른 객체를 알고 있거나 필요한 정보를 계산해서 제공할 수도 있다. - p.139

  • 모델은 실제 엔티티를 복사해서는 안된다. 도메인 주도 설계 첫걸음-Vlad Kononov#^p47

• LOW COUPLING 어떻게 의존성을 낮추고 변화의 영향을 줄이며 재사용성을 증가시킬 수 있을까? 설계의 전체적인 결합도가 낮게 유지되도록 책임을 할당하라. -

  • 결합도는 의존성이다. 다양한 가짓수의 설계에서 의존성 총합을 줄이는 설계를 선택하라.

• HIGH COHESION 어떻게 복잡성을 관리할 수 있는 수준으로 유지할 것인가? 높은 응집도를 유지할 수 있게 책임을 할당하라 -

  • 응집도는 한 번에 초기화하는 인스턴스 변수의 총합이다. 하나 이상의 이유로 클래스가 변경되어야 한다면 응집도가 낮은 것이다. 클래스의 인스턴스를 초기화하는 시점에 서로 다른 속성들을 초기화하고 있다면 응집도가 낮은 것이다. 메서드 그룹이 속성 그룹을 사용하는지 여부로 나뉜다면 응집도가 낮은 것이다.

• 처음부터 책임주도 설계 방법을 따르는 것보다 동작하는 코드를 작성한 후에 리팩터링하는 것이 더 훌륭한 결과물을 낳을 수도 있다.^p174